当调试环境突然弹出许可证异常的提醒时，先别急着去换启动脚本，我们要先弄清楚TRACE32许可证该怎么检查，以及它到期之后功能上到底会受到哪些影响。这个时候需要把两种情况分开来看：一种是软件的服务保障期已经结束了，另一种则是当前的调试核心压根儿就没有对应的许可证。这两种情况都会给出提示，但它们各自影响的范围其实是不一样的。

板卡刚上电进行调试的时候，如果启动脚本的先后顺序编排得不怎么稳当，经常会表现出来的现象包括：连接一会儿好一会儿坏，芯片复位之后程序自己跑飞掉，或者明明符号已经加载成功了，可断点就是打不进去。关于TRACE32的启动脚本该如何去编排，以及上电以后的初始化顺序怎样去确认，比较合理的做法是把一整段PRACTICE脚本拆分成连接、目标初始化、程序加载、调试配置跟运行控制这么几个部分。TRACE32里头的PRACTICE脚本，它的主要用处是拿来做自动配置、测试自动化，还有把系统设置给保存下来，这类脚本一般都会存成.cmm文件，既可以在命令行下用DO命令直接去跑，也能够让别的脚本去调用它。

在调试那些跑着实时操作系统的程序时，光盯着寄存器和函数调用往往是不够的，我们还得弄清楚当前是哪个任务在跑、任务处在什么等待状态、它的优先级是多少，以及栈空间的使用情况。TRACE32的OS Awareness功能要怎么开启，如果任务列表显示不全又该怎么办，处理这些问题的时候，首先要确认操作系统的类型，然后再加载对应的扩展文件。根据TRACE32通用命令的参考说明，OS Awareness是由TASK.CONFIG来配置的，这个命令会载入与内核相关的各种信息；不同的操作系统，它们所支持的资源窗口还有命令也是有所区别的。

程序跑起来以后，变量窗口里的数值一直没有变化，很容易让人以为是代码逻辑根本没有被执行。关于TRACE32变量监视怎么添加，TRACE32变量值刷新异常怎么处理，得先区分出两种情形：一种是在程序暂停下来时去查看变量，另一种是让程序在运行过程中持续刷新。TRACE32提供了Var.View、Var.Watch这些功能，也具备运行时访问内存的能力；但是芯片的架构、缓存、MMU还有调试时的配置，全都会影响最终显示的结果。Lauterbach的文档也说明，程序运行期间能不能直接读写内存，要看目标处理器是否支持对应的访问方式。

在调试Bootloader、应用程序、操作系统的镜像，或者那种分成好几段的固件时，常常会碰到符号文件该怎么加载进去，以及符号里头的地址跟板上实际运行的地址对不上该怎么去修正的问题。在TRACE32这个调试工具里面，当你加载一个ELF或者AXF文件的时候，一般既可以把这个文件里面的代码和数据真正地下载到目标板上去，也可以只把其中的调试符号给加载进去。如果目标板上跑的程序是之前就已经烧进Flash里的，或者是在启动的时候被Bootloader搬到了RAM里面，那就一定要把“把程序下载进去”和“只加载符号”这两种情况分得清清楚楚。按照Lauterbach的教程里说的，Data.LOAD这个命令既可以用来把代码和调试符号一起加载，也可以靠着给它加上一个【/NoCODE】的参数，来实现只加载调试符号的效果。

在嵌入式系统的调试、查看时间先后关系，还有让异常再次出现以及检查代码覆盖情况的阶段，有两个问题经常碰到：TRACE32的Trace窗口要怎么看，另外就是Trace数据被弄丢了通常都跟哪些情况有关系。先要弄明白的是，Trace跟我们平时说的那种日志不一样，它记下来的东西是目标设备在跑的时候生成的程序走向、对数据做读写的动作、时间点标记，还有各种系统里发生的事件。按照Lauterbach那套教程里讲到的，TRACE32可以把Trace记录下来，再通过专门的窗口去展示和分析；而AURIX的培训材料里头也提到了，通过Trace是能够把完整的程序流给展现出来的。

在多核芯片调试的时候，不少人会把“把调试窗口切换到某个核心上去看它里面寄存器的状态”和“只让这一个核心运行、把其他核心都停住”这两个动作当成一回事。要用TRACE32同时调试多个核心，得先把两个基本的事情理清楚：一个是怎么在不同核心之间来回切换，让调试器显示我们想看的那个核心的上下文；另一个是怎么控制多个核心同步地启动和停下来。而要弄清楚这两点，最要紧的一步就是先判断当前的系统处在哪种模式下，是对称多处理（SMP）模式，还是非对称多处理（AMP）模式。TRACE32本身是能够同时挂载好几颗核心一起来调试的，你可以让所有核心同步动作，也可以只盯着其中某一个核心的状态，前提是把下面这些设置和命令弄对了。

调试器能成功连上芯片，并不代表就能把数据稳稳当当地写进Flash里。在TRACE32环境下，Flash烧录要怎么配置，以及烧录过程中如果Flash算法加载失败了又该怎么去排查，关键是把几个方面对应好：目标芯片的连接是不是稳定、Flash的地址范围有没有写对、算法运行时占用的那一段RAM有没有冲突、时钟和总线的配置是不是正确，还有要烧进去的那个文件它的格式和装载地址能不能匹配上。根据Lauterbach的资料，TRACE32支持通过内存映射的方式来编程Flash，它既提供了现成的脚本和编程算法，也可以直接用命令或者脚本来执行烧录操作。

调试环境里如果每次都要手动去点菜单，来做初始化、下载程序、设断点、跑自动化检查这一整套动作，其实是很容易漏掉某个步骤的。想让这些操作自动完成，就要用到TRACE32里的PRACTICE脚本，而很多人比较关心的就是这类脚本到底怎么跑起来，以及万一运行的时候报了错，该从哪些地方下手去查。在动手之前，需要先把脚本的入口在哪、工作目录对不对、参数是不是传全了，还有目标芯片当前的状态，这几件事理清楚，后面会少走很多弯路。按照Lauterbach官方的说明，PRACTICE脚本主要是拿来做自动化配置、自动化测试序列，以及保存系统设置的；在命令行那里，用【DO】命令就可以启动一个PRACTICE脚本，在脚本里面，也照样能用【DO】去调用另一个脚本，一层层配合起来。

在实际调试中，TRACE32的JTAG速度怎么设定，以及连接时钟拉得太高会带来什么问题，这两个情况现场经常碰到。JTAG速度，本质上就是调试器跟目标芯片之间那根TCK时钟线上的频率；把频率调高一些，下载程序、读写内存和刷新变量这些操作确实能变快，可当板子上信号质量不够好、芯片上电后状态还不稳定、调试接口设计本身有缺陷，或者目标器件内部的时钟跟不上时，速度开得太高反而会让连接失败。在Lauterbach的调试会话教程里，也有这样的顺序：先选CPU、再按需要调整JTAG clock、接着设置芯片相关选项、最后建立通信。